Methods and Devices for Supplying Quality of Service Parameters in Http Messages

ABSTRACT

The present invention relates to changing of Quality of Service parameters to adapt a transmission to varying transmission capacity demands. According to the method of the present invention a message from a second network node  320  is received by a first network node  310  as a response of the content request from a client terminal  105 . The message should contain the requested content and information on required quality of service parameters for delivering the content to the client terminal. The information on required quality of service parameters is read by the first network node  310  to determine second quality of service parameters, whereby facilitating an update of quality of service parameters to the second quality of service parameters.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to commonly assigned co-pendinginternational patent application No. PCT/SE04/______, entitled “BindingMechanism for Quality of Service Management in a Communication Network”,filed on Jul. 5, 2004; international patent application No.PCT/SE04/______, entitled “Methods and Devices for Changing Quality ofService”, filed on Jul. 5, 2004; and international patent applicationNo. PCT/SE04/______, entitled “Devices and Methods for Push MessageInitiated Service”, filed on Jul. 5, 2004, the disclosures of which areincorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to methods and devices in mobilecommunication systems offering packet data service. In particular theinvention relates to an end user utilizing services offered by anservice provider, via an client terminal, and to the use of Quality ofService classes to adapted a transmission to an expected grade ofservice.

BACKGROUND

Modern mobile communication systems providing packet switched services,such as Universal Mobile Telecommunication System (UMTS) should becapable of supporting a large and diverse variety of applications havingdifferent demands on needed transmission capacity, sensitivity to delaysin the transmission and demands on interactivity, for example. Theapplications range from a simple transfer of a text message, which is anexample of an application that does not require high capacity nor istime critical, to video conferencing, which is a real time applicationrequiring high transmission capacity. The concept of Quality of Service(QoS) was introduced to ensure that an end user, running an application,receives the system resources required for that particular application.At the same time, by not using more recourses than necessary for theapplication, the use of QoS contributes to the optimization of the useof the system resources, in particular the scarce radio resources. HowQoS is implemented in UMTS is described in the technical specifications3GPP TS 23.107 V6.1.0 (2004-03) and 3GPP TS 23.207 V6.2.0 (2004-03).

Illustrated in FIG. 1 is a generic mobile communication system whereinQoS may be utilized. The mobile communication system 100 comprises aclient terminal 105 which may communicate with a network node, forexample an application server 120, to use service provided by a serviceprovider, for example. The client terminal 105 should be seen as arepresentation of various equipment, including, but is not limited to,mobile (cellular) phones, laptop computers and PDAs with communicationabilities, and is also commonly referred to as User Equipment (UE) orMobile Station (MS). A radio access network (RAN) 125, a core network(CN) 130 and a service network (SN) 135 are involved and interacting inproviding the communication between the client terminal 105 and theapplication server 120.

In UMTS QoS is defined with a set of attributes that specifies the UMTSbearer service. The UMTS QoS attributes are the following:

-   -   Traffic class    -   Maximum bit-rate    -   Guaranteed bit-rate    -   Delivery order    -   Maximum SDU size    -   SDU format information    -   SDU error ratio    -   Residual bit error ration    -   Delivery of erroneous SDUs    -   Transfer delay    -   Traffic handling priority    -   Allocation/Retention Priority    -   Source statistics descriptor    -   Signalling Indication

These attributes can be mapped to the pre-defined UMTS QoS classes:Conversational class, Streaming class, Interactive class and Backgroundclass. The QoS classes are specified to the communication system by thePacket Data Protocol (PDP) context.

FIG. 2 illustrates schematically communication between a client terminal105 and the application server 120 in UMTS. The communication occurs viathe RNC (Radio Network Controller) 205 and the main nodes SGSN (ServingGPRS support node) 210 and GGSN (Gateway GPRS support node) 215 of theCN 130, to the application server 120 in the SN 135.

In the prior art UMTS implementations the QoS classes are negotiated andmanaged by using PDP context management. Application level QoSrequirements are mapped to PDP context parameters in the clientterminal. Pre-configurations of PDP contexts are made in the clientterminal such that when a packet switched application starts andconnects to the network a matching pre-configured PDP context isactivated. This PDP context has a selected QoS class that should matchthe desired QoS requirements of the application. If for instance theapplication is a WAP or HTTP browser, the QoS class of the activated PDPcontext is usually the Interactive class, which is a type of “besteffort”. Illustrated in FIG. 2 with an arrow 220, is the PDP context,defining the required QoS class, originating from the client terminal115 and received by the GGSN 215.

Today, an application, or service node, for example a WWW server mayinfluence the selection of QoS class performed in the client terminal bythe Session Description Protocol (SDP). The W server may want, in orderto effectuate a streaming session, for example, to use a another bearerbetter suited for the download, than the already in use. The WWW servermay then issue a SDP document to the client terminal, specifying thedesired QoS class. Subsequently, the client terminal will have toinitiate the actual change of QoS, before the downloading can beperformed.

In short, the selection of QoS class can be seen as a process controlledby an application in the client terminal and typically performed duringthe establishment of a communication session. The selection of QoS classis typically, in practice, static for the session. However, it is wellrecognized that a browsing session, for example, may exhibit veryvarying demands on the amount of information to be transferred to theend user. For example in searching, selecting and downloading mediafiles such as music- or videoclips, the searching and selecting imposevery moderate demands on the speed of the transfer, whereas the actualdownloading may need a bearer of 128 Kb/s or preferably even higher. Toconstantly use the QoS class only necessary for the most demanding taskin a browser session is a waste of radio resources and have a negativeimpact on the battery life of especially user equipment, since typicallymore power is consumed while using the high capacity transfer. Thus,there is a need for devices and methods that better adapt to thefluctuations of the required QoS.

SUMMARY OF THE INVENTION

An object of the present invention is to provide devices and methodsthat allow a for a network node, or an application in an network node,in the service network to determine appropriate QoS parameters for abearer service between the client terminal and the application, and toinitiate an update of quality of service.

The above stated object is achieved by means of a method in a networknode according to claim 1, a network node according to claim 24 andcomputer program products according to claims 21 and 22.

The basic idea of the present invention is to provide a method andarrangement in a first network node so that the network node may easilydetermine required QoS parameters suitable for a certain content. Amessage from a second network node is received by the first network nodeas a response of the content request from a client terminal. The messageshould contain the requested content and information on required qualityof service parameters for delivering the content to the client terminal.The information on required quality of service parameters is read by thefirst network node to determine second quality of service parameters,whereby facilitating an update of quality of service parameters to thesecond quality of service parameters. The method may further identify arequirement for changing quality of service parameters during an ongoingcommunication session and initiate a modification of quality of serviceparameters.

According to a first aspect of the present invention a method in thenetwork node is provided which comprises the steps of:

-   -   receiving a content request issued by the client terminal;    -   forwarding the request to the second network node;    -   receiving a message from the second network node as a response        of the forwarded request, the message comprising the requested        content and information on required quality of service        parameters for delivering the content to the client terminal;    -   reading from the message the information on required quality of        service parameters, and determining second quality of service        parameters based on said information on required quality of        service parameters; and    -   issuing an update from the initial quality of service parameters        to the second quality of service parameters.

Whereby a delivery of a response to the content request can be performedwith the use of the second quality of service parameters.

According to a second aspect of the method of present invention themessage is a dedicated MIME-type.

According to a third aspect of the method of present invention themessage comprises at least one content part and at least one header partand wherein the quality of service information is provided in the headerpart. The message may for example be a HTTP response message and thequality of service information is provided in a header line.

According to a fourth aspect of the method of present invention theinformation on required quality of service parameters is arepresentation of a quality of service class, preferably from the groupof pre-defined UMTS quality of service classes comprising:conversational class, streaming class, interactive class and backgroundclass.

According to a fifth aspect of the method of present invention, themethod may further comprise a step of determining if quality of serviceparameters should be updated, said determining based on a comparison(510) of the initial quality of service parameters with the secondquality of service parameters, and wherein the step of issuing only istaken if an update is determined in the determining step.

The network node according to the invention is adapted to provide accessto services from a service provider in a communication session wherein aclient terminal utilizes services provided via the network node andwherein initial quality of service parameters are used. The network nodecomprises:

-   -   quality of service determining means, adapted to, on a content        request issued by the client terminal, determine second quality        of service parameters associated to the requested content The        quality of service determining means is adapted for        communication with interface means for interfacing a second        network node. The interface means is adapted to forwarding and        receiving messages to and from the second network node, and is        adapted to read or decode the messages from the second network        node; and    -   quality of service modification means adapted to issue an update        from the initial quality of service parameters to the second        quality of service parameters, by the use of an update PDP        context message.

Thanks to the invention a network node may identify that a response to acontent request would benefit from a change of quality of serviceparameters during an ongoing communication session. If appropriate thenetwork node initiates and effectuates the change of quality of serviceparameters.

One advantage afforded by the present invention is that thecommunication system better adapts to varying needs in bearer capacity,typically occurring in a browsing-downloading scenario, wherein mediafiles are downloaded via the network node to the client terminal.

A further advantage is that thanks to the invention, a more efficientuses of the scarce radio resources is made possible, since unnecessaryhigh quality of service, i.e. high bearer capacity, is avoided at timesthen not explicitly needed.

Yet a further advantage is that since high bearer capacity is used onlythen explicitly necessary the power consumption is kept at a minimum.This is of greatest importance in user equipment since the battery lifehence is prolonged.

Yet a further advantage of the arrangement of the present invention isthat the content and the quality of service parameters suitable fordelivering the content is contained within the same message. In that waythe number of messages exchanged between the first and second networknode can be reduced and a reliable connection between the content andthe quality of service parameters is achieved.

Further advantages and features of embodiments of the present inventionwill become apparent when reading the following detailed description inconjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic illustration of a generic mobile communicationsystem;

FIG. 2 is a schematic illustration of the use of PDP context in a mobilecommunication system;

FIG. 3 a is a schematic illustration of a mobile communication systemtherein the method and arrangements according to the present inventionmay by used, and 3 b is a schematic illustration of the functional partsimplemented as software code means of the network node according to theinvention;

FIG. 4 is a signal/message sequence scheme illustrating the methodaccording to the present invention;

FIG. 5 a is a flowchart of the method according to the presentinvention, and 3 b a flowchart of one embodiment of the method accordingto the present invention;

FIG. 6 is a schematic illustration of the MIME-type according to oneembodiment of the present invention; and

FIG. 7 is a schematic illustration of the HTTP response header accordingto one embodiment of the present invention.

DETAILED DESCRIPTION

The present invention will now be described more fully hereinafter withreference to the accompanying drawings, in which preferred embodimentsof the invention are shown. This invention may, however, be embodied inmany different forms and should not be construed as limited to theembodiments set forth herein; rather, these embodiments are provided sothat this disclosure will be thorough and complete, and will fullyconvey the scope of the invention to those skilled in the art. In thedrawings, like numbers refer to like elements.

The present invention is applicable to packet switched services in amobile communication system, which services typically are provided by aservice provider and utilized by an end user with the aid of a clientterminal. In particular the present invention relates, but is notlimited, to scenarios wherein the end user is browsing web-pages or thelike to find and download content such as music, pictures and movieclips, which hereinafter will be referred to as media files. A usagethat is characterized by very varying demands on the transmissioncapacity—for the browsing a “best effort” transmission often suffice,while a download of a media file, for example, impose very high demandson the transmission capacity. As described in the background sectionprior art methods and arrangement fail to accommodate to the rapidchanges in demands of transmission capacity during certain applicationssuch as downloading of media files.

FIG. 3 is a schematic view of a mobile communication system in which thepresent invention may be used. The mobile communication system 100comprises a client terminal 105 which may communicate with a networknode 310 of a service provider and thereby receive a service that isoffered by the service provider. The network node 310 is typically aproxy for the client terminal 105 in the utilization of a WWW-server320. The communication between the client terminal 105 and the networknode 310, typically involves three separate but interconnected networks,the radio access network (RAN) 125, the core network (CN) 130 and theservice network (SN) 135. Possible radio access networks 125 includes,but is not limited to, WCDMA, CDMA2000, Wireless LAN or GPRS network.The core and service networks are commonly realized as IP-based orATM-based communication networks.

The client terminal 105 resides in the radio access network (RAN) 125,which is controlled by at least one Radio Network Controller (RNC) 205which is in communication with a Serving GPRS support node (SGSN) 210 ofthe core network 130. The CN 130 are via Gateways nodes in communicationwith other networks. The Gateway GPRS support node (GGSN) 215interconnects the CN 130 with the service network 135. The GGSN 215 mayfurther communicate with a session database 317. The network node 310,or proxy, of which the client terminal 105 communicates is part of theservice network 135, and may in turn be connected to a further networksnode providing the actual service, for example a WWW server 320, an MMSserver 325 or application other types of application servers. All ofwhich are part of the service network 135. The network node 310, orproxy, may also be in connection to servers which are not part of theservice network 135, but belongs to external networks 335.

According to the present invention is to provide a method andarrangement is provided in a first network node 310 so that the networknode may easily determine required QoS parameters suitable for a certaincontent. A message from a second network node 320, 325 is received bythe first network node 310 as a response of the content request from theclient terminal 105. The message should contain the requested contentand information on required quality of service parameters for deliveringthe content to the client terminal. The information on required qualityof service parameters is read by the first network node 310 to determinesecond quality of service parameters, whereby facilitating an update ofquality of service parameters to the second quality of serviceparameters. The method may further identify a requirement for changingquality of service parameters during an ongoing communication sessionand initiate a modification of quality of service parameters. Theprocess is preferably initiated by and controlled by an application inthe network node 310.

The method and arrangement according to the invention will be describedin an UMTS network and with reference to the schematic signalling schemedepicted in FIG. 4 and the flowchart of FIGS. 5 a and 5 b. Embodimentsof the present invention are illustrated in FIG. 6 and FIG. 7.

The method according to the present invention is applicable during acommunication session between the client terminal 105 and the networknode 310, as illustrated by the signalling scheme of FIG. 4. On anapplication layer the communication is between an terminal application,for example a browser 405, and the application of the service provider410, via the proxy application 415 in the network node 310. Thecommunication session has been set up according to the standardprocedures which are known in the art. Only the steps of the set upprocedure necessary for the understanding of the inventive method willtherefore be described. The steps of setting up the communicationsession should not be regarded as part of the invention.

A communication session typically begins with an end user initiating apacket service application in the client terminal 105, by starting a WEBbrowser 405, for example. In UMTS PDP context management is used to setup the session with appropriate QoS class, among other parameters. Uponstarting an application in the client terminal 105 the application levelQoS requirements are mapped to PDP context parameters in the clientterminal, typically by activation of a pre-configured PDP contextspecifying a QoS class which should match the applications QoSrequirements. A negotiation process involving the SGSN 210 and the GGSN215, establish initial QoS parameters to be used in the communicationsession, as illustrated in the set up part 407 of FIG. 4. The GGSN 215stores PDP context information in the session data base, indicated byarrow 410. After completion of the set up the communication sessionproceeds with the establishment of the application level communication,arrow 415, in the current example a WEB browsing session, between theapplication (browser) in the client terminal 105 and the proxyapplication of the network node 310.

During the web browsing a content request is issued from the applicationof the client terminal 105, for example a request of downloading a mediafile from the WWW server, arrow 420. One example of a content request isa “HTTP GET” message issued to the proxy application 415 of the networknode 310. The proxy forwards the request to the WWW server, arrow 425.The WWW server prepares a message comprising both the content andinformation on the required QoS parameters for effective deliverance ofthe content, and issues the message as a HTTP response to the proxy,arrow 427. The proxy receives the message, reads and analyze the QoSparameters, and possibly prepares a content delivery according to theabove described. The association of QoS parameters to the content willbe further discussed below.

The network node 310 initiates a process for modifying 440 the QoSparameters used in the session by issuing an update of PDP context, tothe GGSN 215. The network node 310 needs to have information on whichGGSN 215 to address, and preferably also include information which theGGSN 215 may use to identify the client terminal 105. Preferably, thenetwork node 310 retrieves this information from the session database317, which will be further discussed below. The further PDP updatingprocess, arrows 440:2, 3, 4, 5, 6, involves the GGSN 215, SGSN 210, RNC205 and the Client terminal 105 is performed according to the standard,and hence is well known for the skilled in the art. The GGSN 215forwards the PDP context response issued by the client terminal 105 toinform the network node 100 of the result of the updating process,arrows 440:7.

The result of the updating process is either that the communication isnow occurring according to the requested QoS defined by the second QoSparameters, or that it was not possible to comply to the requestedupdate, for example due to temporary constrains in the radioenvironment. In the latter case the updating process may result in a QoSthat is lower than the requested (second QoS parameters), but possiblyhigher than the initial QoS parameters. The network node 310 will thenhave to decide if the content should be delivered with the available QoSor if the process should be abandoned. In most cases a media file willbe practically impossible to transfer, or at last highly inconvenient,below a certain transfer right. Accordingly, the network node 310 shouldin most cases choose to abandon the delivery process if the suitable QoScan not be used. Information on if lower QoS than the requested couldstill be used for the content (file type) in question, may be includedin the second QoS parameters or communicated to the network node 310 byother means.

Upon completion of the Update PDP context, the network node 310 deliversthe requested content to the client terminal 105, arrow 450, wherein thesecond QoS parameters are used.

Alternatively the network node 310 determines if a modification of theQoS parameters used in the session would benefit the delivery of thecontent to the client terminal 105 by comparing the initial QoSparameters with the second QoS parameters 430. The network node 310preferably retrieves information on the initial QoS parameters from thePDP context information stored in the session database 317.

If the network node 310 has determined a change to the temporary QoSparameters, e.g. if the initial QoS parameters corresponds to a lowerQoS class than the second QoS parameters the modification process isinitiated according to the above described. If not, the QoS do not needto be updated in order for the network node 310 to effectively respondto the request.

The application of the network node 310 may further check if therequested QoS comply with the capabilities of the client terminal 105and with the restrictions of the end user's subscription. A processoften referred to as policy check, and which is known in the art. Animproved policy check, that may be advantageously utilized in thisinvention is taught in the above referred application “Binding Mechanismfor Quality of Service Management in a Communication Network”.

The network node 310 may after completion of the delivery of the mediafile, for example, initiate a return to the initial QoS parameters 460.This is performed by an Update PDP context, identical to the Update PDPcontext described above.

The process of changing QoS during the communication session isaccording to the method of the invention initiated and controlled fromthe network node 310. The method in the network node 310 is illustratedin the flowchart of FIG. 5 a and comprises the steps of:

505: Determining, on an content request issued by the client terminal105, second QoS parameters, or a representation of second QoSparameters, associated to the requested content by:

-   -   505:1 Forwarding the content request to a second network node,        for example a service provider server.    -   505:2 Receiving a message from the second network node as a        response of the forwarded content request of step 505:1.        Contained within the message is the requested content and        information on required QoS parameters for delivering the        content to the client terminal 105.    -   505:3 Reading from the message the information on required QoS        parameters and determining second QoS parameters based on said        information on required quality of service parameters. The        required QoS parameters may be in a format directly usable as        the second QoS parameters, a specification of a QoS class or a        alphanumeric representation which the application of the network        node 310 may convert to second QoS parameters.

520: Initiate a modification of quality of service parameters by issuingan update from the initial quality of service parameters to the secondquality of service parameters.

525: Delivering the requested content to the client terminal 105 withthe use of the second QoS parameters.

In many cases it would be favourable to check if the modification ofquality of service parameters is necessary, for example to check if theused initial QoS parameters are the same as the second. An alternativeembodiment of the method according to the invention comprises theadditional steps, to be taken prior to the issuing step (520), of:

510: Comparing the initial QoS parameters with the second QoSparameters.

515: Determining if the QoS parameters should be updated, based on thecomparison in step 510. If the second QoS parameters indicate a QoS thatis higher, i.e. requires higher bearer capacity, than the QoS in use(the initial QoS parameters) a requirement for updating QoS parametersis identified, for effectuating the content delivery. If not, thecontent delivery may be performed with the initial QoS parameters, i.e.the QoS parameters do not need to be updated, and hence, the issuingstep (520) is not to be taken.

The method may in addition comprise the optional steps of:

523: Preparing the response to the client terminal by removing theinformation on the QoS parameters from the message.

As discussed above the message (HTTP response) should contain both thecontent and QoS parameters, or a representation of QoS parameters,required for the delivery of the response. The message should preferablybe of a type that can be widely used and interpreted. A suitable formatfor the combined content and QoS information may be based onMultipurpose Internet Mail Extensions (MIME). MIME refers to an officialInternet standard that specifies how messages must be formatted so thatthey can be exchanged between different systems and has become widelyused in for example downloading content via browsers. MIME is a veryflexible format, permitting one to include virtually any type of file ordocument in an email message. Specifically, MIME messages can containtext, images, audio, video, or other application-specific data. Adescription of MIME can be found in the IETF (Internet Engineering TaskForce) publication RFC 1521, 1522.

According to the present invention, in order to meet the demands onflexibility in the use of QoS parameters arising from the varyingrequirements during a browsing session, a new MIME-type is introduced.The new MIME-type is illustrated in FIG. 6. The MIME-type comprises,among other fields, a main header 605, content-type 607, transferencoding 610 and content 615, which also is present in the prior artMIME. In the MIME-type according to the invention a new field isintroduced, the QoS field 620, specifying the required or desired QoSneeded to efficiently transfer the MIME message. The QoS field ispreferably, but not necessarily a subfield to the field “content type”.The use of the new MIME-type offers an effective way of exchanging thecontent and the QoS information. One prerequisite is that theapplication of the network node 310 needs to have knowledge about thisparticular MIME-type in order to correctly use the QoS information andto prepare a message which is understandable for the client terminal105.

As an alternative to using the modified MIME, the information on QoS canbe contained in a HTTP header, which represents an alternativeembodiment of the invention. In this embodiment, the second networknode, e.g. the WWW server, prepares a regular HTTP response,schematically illustrated in FIG. 7, which typically includes a statusline 705 indicating version, status code etc, a plurality of headerlines 710 which could specify content type and content length, and anentity body 715 comprising the actual data. According to the embodimentof the invention also QoS information is included in the header,preferably as a QoS line 711 among the other header lines specifyingcontent type, size etc. This message format is very versatile. If, forexample, the QoS information provided in the header line 711, is notunderstandable to the proxy application of the network node 310, thisinformation will simply be discarded and the HTTP response deliveredanyway. However, probably not with the optimum QoS parameters.

In several steps of the method described with reference to FIG. 5,information on the ongoing communication is needed. Such information isadvantageously retrieved from the session database 317. The step 510 ofcomparing the initial QoS parameters with the second QoS parameters, maycomprise the substeps of:

510:1 Accessing the session database 317 to retrieve the PDP informationassociated with the communication session.

510:2 Reading from the PDP information the initial QoS parameters. TheQoS are preferably stored as “Negotiated QoS” defined in the 3GPP TS24.008.

510:3 Optionally reading addressing information from the PDPinformation.

The step 515 of determining if the QoS parameters should be updated maycomprise the substeps of:

515:1 Storing temporarily the initial QoS parameters to be used in theoptional returning to the initial QoS parameters.

The method may in addition comprise the optional steps of:

522: Optionally accessing the session database 317 to update the PDPinformation with the second QoS parameters. The step to be taken afterthe modifying step 520 and prior to the delivering step 525.

530: Returning to the use of the initial QoS parameters by issuing anupdate from the second QoS parameters to the initial QoS parameterssimilar to step 520. The step to be taken after the delivering step 525.

The information optionally read by the network node 310 in step 510:3may primarily be used for the application to find end-users GGSN 215 andfor the GGSN 215 to map the request to the right GTP (GPRS TunnelProtocol), i.e. to find the GTP associated with the client terminal 105.Table 1 specifies information concerning addressing that is contained(among other information) in the PDP information of the session database317 related to the ongoing communication session. TABLE 1 Attributes inthe Session database NAS IP Address The IP address of the RADIUS clientthat sent the request. This is usually the IAS or GGSN. IP Address TheIP address that is allocated to the terminal. Calling Station The MSISDNof the Id connected terminal (MSISDN) IMSI The International MobileSubscriber Identity Negotiated QoS The negotiated quality of service asdefined in 3GPP TS 24.008

The NAS IP address can be used by the application of the network node310 to send the “Update-PDP-request” to the right GGSN 215. IMSI (orMSISDN) can preferably be included in the message from the network node310 for the GGSN 215 to find the right GTP. Alternatively the sessiondatabase is updated with a GTP identifier, which directly identifies theGTP of the ongoing communication session.

A most preferred embodiment, comprising a plurality of the presentedsubsteps and options is illustrated in the flowchart according to FIG. 5b, comprises the steps of:

505: Determining, on an content request issued by the client terminal105, second QoS parameters, or a representation of second QoSparameters, associated to the requested content by:

-   -   505:1 Forwarding the content request to a second network node,        for example a service provider server.    -   505:2 Receiving a message from the second network node as a        response of the forwarded content request of step 505:1.        Contained within the message is the requested content and        information on required QoS parameters for delivering the        content to the client terminal 105.    -   505:3 Reading from the message the information on required QoS        parameters and determining second QoS parameters based on said        information on required quality of service parameters. The        required QoS parameters may be in a format directly usable as        the second QoS parameters, a specification of a QoS class or a        alphanumeric representation which the application of the network        node 310 may convert to second QoS parameters.    -   505:4 Preparing the response to the client terminal by removing        the information on the QoS parameters from the message.

510: Comparing the initial QoS parameters with the second QoS parametersby:

-   -   510:1 Accessing the session database 317 to retrieve the PDP        information associated with the communication session.    -   510:2 Reading from the PDP information the initial QoS        parameters. The QoS are preferably stored as “Negotiated QoS”        defined in the 3GPP TS 24.008.    -   510:3 Reading addressing information from the PDP information.

515: Determining if the QoS parameters should be updated, based on thecomparison in step 510. If the second QoS parameters indicate a QoS thatis higher, i.e. requires higher bearer capacity, than the QoS in use(the initial QoS parameters) a requirement for updating QoS parametersis identified, for effectuating the content delivery. If not, thecontent delivery may be performed with the initial QoS parameters, i.e.the QoS parameters do not need to be updated. Storing temporarily(substep 515:1) the initial QoS parameters to be used in the optionalreturning to the initial QoS parameters.

520: Initiate a modification, if a requirement of modification isidentified in the determining step, of quality of service parameters byissuing an update from the initial quality of service parameters to thesecond quality of service parameters.

522: Accessing the session database 317 to update the PDP informationwith the second QoS parameters.

525: Delivering the requested content to the client terminal 105 withthe use of the second QoS parameters.

530: Returning to the use of the initial QoS parameters by issuing anupdate from the second QoS parameters to the initial QoS parameterssimilar to step 520.

The term “second QoS parameters” should be interpreted in a broad sense.i.e. not restricted to parameters explicitly specifying a bit rate, forexample. The second QoS parameters may, for example, be a representationof the pre-defined UMTS QoS classes or a representation of an acceptablebit rate range. The representations being decodable by the proxyapplication of the network node.

In a further embodiment of the present invention the second QoSparameters comprises at least two representations of different QoSlevels or classes. A first representation, the desired QoS level,specifying a level (bit rate, for example) to which the content isadapted, and a second representation, the minimum QoS level, specifyingthe lowest QoS level with which the delivery can still be performed. Theapplication of the network nod may then, upon a negative response to thedesired QoS level, either from the policy check or in the Update PDPcontext response, chose the minimum QoS level, or a level in-between,for the delivery of the content.

The network node 310 according to the present invention comprises aplurality of functional parts, preferably implemented as software codemeans, to be adapted to effectuate the method according to theinvention. In FIG. 3 b are the main functional parts, which are involvedin an change of QoS during a communication session, schematicallydepicted. The terms “comprising” and “connected” should here beinterpreted as links between functional parts and not necessarilyphysical connections.

The network node comprises communication means 350 for communicating onan application level with a client terminal 105 and QoS determiningmeans 360, adapted to, on an content request issued by the clientterminal 105, determine second QoS parameters associated to therequested content. The QoS determining means 360 preferably comprises,or is connected to interface means 361 for interfacing a second networknode which is adapted to forwarding and receiving messages to and fromthe second network node, and adapted to read or decode the messages fromthe second network node, especially to read QoS information contained inthe messages.

The comparing means 370 of the network node 310 is adapted to comparethe initial QoS parameters with the second QoS parameters and istherefore preferably connected to a session database interface 371 foraccessing the session database 317 to retrieve the PDP informationassociated with the communication session and is adapted to read theinitial QoS parameters and possibly also addressing information from thePDP information.

The updating determining means 380 is adapted to determine if the QoSparameters should be updated, based on the comparison provided by thecomparing means 370. The updating determining means 380 identifiesrequirement for updating QoS parameters if the second QoS parametersindicate a QoS that is higher, i.e. requires higher bearer capacity,than the QoS in use (the initial QoS parameters). The updatingdetermining means 380 may comprise, or be connected to storing means 381for storing the initial QoS parameters.

The QoS modification means 390 is adapted to issue an update from theinitial quality of service parameters to the second quality of serviceparameters, by the use of update PDP context message. The update PDPcontext message should be directed to the appropriate GGSN 215 and istherefore provided with, or connected to, GGSN interface means 391. TheQoS modification means may further be adapted to retrieve addressinginformation from the PDP information and is therefore connected to thesession database interface 371.

1. A method in a first network node in a mobile communication networkfor changing quality of service parameters during an ongoingcommunication session between the first network node and at least oneclient terminal using initial quality of service parameters, wherein thefirst network node is in communication with a second network node, themethod comprising the steps of: receiving a message from the secondnetwork node by the first network node as a response of a contentrequest from the client terminal, said message comprising the requestedcontent and information on required quality of service parameters fordelivering the content to the client terminal, reading the informationon required quality of service parameters by the first network node todetermine second quality of service parameters, and facilitating anupdate of quality of service parameters to the second quality of serviceparameters.
 2. The method according to claim 1, further comprising thesteps of: receiving a content request issued by the client terminal;forwarding the request to the second network node; receiving a messagefrom the second network node as a response of the forwarded request, themessage comprising the requested content and information on requiredquality of service parameters for delivering the content to the clientterminal; reading from the message the information on required qualityof service parameters, and determining second quality of serviceparameters based on said information on required quality of serviceparameters; and issuing, an update from the initial quality of serviceparameters to the second quality of service parameters and facilitatinga delivery of a response to the content request with the use of thesecond quality of service parameters.
 3. The method according to claim1, wherein the message is a dedicated MIME-type.
 4. The method accordingto claim 1, wherein the message comprises at least one content part andat least one header part and the quality of service information isprovided in the header part.
 5. The method according to claim 4, whereinthe message is an HTTP response message and the quality of serviceinformation is provided in a header line.
 6. The method according toclaim 3, wherein the information on required quality of serviceparameters is a representation of a quality of service class.
 7. Themethod according to claim 6, wherein the quality of service class arefrom a group of pre-defined UMTS quality of service classes comprising:conversational class, streaming class, interactive class and backgroundclass.
 8. The method according to claim 1, further comprising, prior tothe issuing step the step of: determining if quality of serviceparameters should be updated, said determining based on a comparison ofthe initial quality of service parameters with the second quality ofservice parameters, wherein the step of issuing is taken only if anupdate is determined.
 9. The method according to claim 8, wherein thestep of comparing quality of service parameters comprises retrievinginformation on the initial quality of service parameters from a sessiondatabase.
 10. The method according to claim 9, wherein the step ofretrieving information comprises the steps of: accessing the sessiondatabase to retrieve Packet Data Protocol (PDP) information associatedwith the communication session; and reading from the PDP information theinitial QoS parameters.
 11. The method according to claim 10, whereinthe step of retrieving information further comprises a step of: readingaddressing information from the PDP information.
 12. The methodaccording to claim 11, wherein the addressing information comprises aNAS IP address which is used by the network node to identify a GatewayGPRS support node (GGSN) which is controlling part of the communicationwith the mobile client terminal
 105. 13. The method according to claim12, wherein the addressing information comprises IMSI or MSISDN for theclient terminal, which IMSI or MSISDN the network node include in amessage to the GGSN for identifying GPRS Tunnel Protocol (GTP)associated with the ongoing communication session.
 14. The methodaccording to claim 1, wherein in the step of comparing quality ofservice parameters, a requirement for modifying quality of serviceparameters is identified if the initial quality of service parametersdiffer from the second quality of service parameters.
 15. The methodaccording to claim 14, wherein in the step of comparing quality ofservice parameters, a requirement for modifying quality of serviceparameters is identified if the initial quality of service parameterscorrespond to a lower transfer rate than the transfer rate correspondingto the second quality of service parameters.
 16. The method according toclaim 6, wherein the initial quality of service parameters is arepresentation of a first quality of service class.
 17. The methodaccording to claim 16, wherein the first quality of service class isfrom the group of pre-defined UMTS quality of service classescomprising: conversational class, streaming class, interactive class andbackground class.
 18. The method according to claim 1, furthercomprising the steps of: storing the initial quality of serviceparameters; and returning to the use of the initial quality of serviceparameters after completion of the response to the request.
 19. Themethod according to claim 18, further comprising the step of: accessingthe session database to update the PDP information with the second QoSparameters.
 20. The method according to claim 1, further comprising astep of preparing the response to the client terminal by removing theinformation on the QoS parameters from the message. 21.-22. (canceled)23. A network node in a mobile communication network adapted to provideaccess to services from a service provider in a communication sessionwherein a client terminal utilizes services provided via the networknode and wherein initial quality of service parameters are used, thenetwork node comprising: quality of service determining means, adaptedto, on a content request issued by the client terminal, determine secondquality of service parameters associated to the requested content, saidquality of service determining means adapted for communication withinterface means for interfacing a second network node, said interfacemeans adapted to forwarding and receiving messages to and from thesecond network node, and adapted to read or decode the messages from thesecond network node; and quality of service modification means adaptedto issue an update from the initial quality of service parameters to thesecond quality of service parameters, by the use of an update PDPcontext message.
 24. The network node according to claim 23, wherein theinterface means is adapted to read quality of service informationcontained within a messages from the second network node.
 25. Thenetwork node according to claim 23, further comprising comparing meansadapted to compare the initial quality of service parameters with thesecond quality of service parameters.
 26. The network node according toclaim 25, wherein the comparing means is adapted for communication witha session database interface for accessing a session database toretrieve PDP information associated with the communication session. 27.The network node according to claim 26, wherein the session databaseinterface is adapted to read the initial quality of service parametersfrom the PDP information.
 28. The network node according to claim 26,wherein the session database interface is adapted to read addressinginformation from the PDP information.
 29. The network node according toclaim 23, further comprising updating determining means adapted todetermine if quality of service parameters in an ongoing communicationsession should be updated, based on the comparison provided by thecomparing means, said updating determining means being adapted toidentify a requirement for updating quality of service parameters if thesecond quality of service parameters indicate a quality of servicedifferent from a quality of service indicated by the initial quality ofservice parameters.
 30. The network node according to claim 29, whereinthe updating determining means comprises storing means for storing theinitial quality of service parameters.
 31. The network node according toclaim 23, wherein the quality of service modification means is adaptedfor communication with a GGSN interface means for providingcommunication facilities to at least one GGSN.
 32. The network nodeaccording to claim 26, wherein the quality of service modification meansis adapted for communication with the session database interface toretrieve addressing information from the PDP information.